LocalStack versus Spinifex comes up often enough to address directly. They don't compete because they solve different problems at different points in the software lifecycle. Conflating the two leads to reaching for the wrong tool and being frustrated when it doesn't fit.
What LocalStack is for
LocalStack is an AWS emulator. You run it locally in a Docker container and it intercepts calls to AWS API endpoints, returning responses that closely approximate what the real AWS would return. It covers over 120 services and understands the same SDKs, CLI commands, and Terraform provider that you use against real AWS. For local development and CI testing, it's excellent: you can write a Lambda that reads from S3, test it locally against a LocalStack instance, and be confident the code will behave the same way in AWS without incurring API costs or requiring a real AWS account to be wired into your local dev loop.
The emulation is not perfect at the edges, and LocalStack itself is clear that it's a development tool rather than a production platform. State is ephemeral by default, meaning a container restart loses everything. There are no real virtual machines being managed, no actual block storage with persistence guarantees, and no genuine network enforcement between services. The goal is behavioural approximation fast enough to run in a developer's inner loop, not correctness guarantees at the margins.
In March 2026, LocalStack archived its Community Edition GitHub repository and moved core services behind a paid plan, which drew a strong reaction from the developer community given the project had accumulated over 64,000 GitHub stars. A permanent free tier remains available for non-commercial use, and students and open-source projects can access the full suite without charge, but the Base plan covering persistent state via Cloud Pods costs $45 per month. That change is largely why "LocalStack alternative" has become a high-volume search query, and it's a reasonable frustration for teams that relied on CE for commercial CI pipelines.
What Spinifex is for
Spinifex is not a development tool and not an emulator. It implements the AWS API surface on real bare metal hardware so that the hardware you own becomes the production environment, while preserving every piece of AWS tooling you've already built competency around. EC2 calls provision actual virtual machines with real CPU and memory allocation. EBS volumes are actual block storage with real persistence guarantees. IAM policies are enforced across real network boundaries. The S3-compatible object storage layer, Predastore, distributes objects across nodes using Reed-Solomon erasure coding so data survives node failures.
The use case is environments where AWS itself isn't available or appropriate: disconnected field deployments, air-gapped secure facilities, data sovereignty requirements that prohibit data leaving infrastructure under your direct control, and workloads where owning the hardware is more economical than cloud compute and egress costs. Spinifex runs without any external control plane or cloud dependency and installs from a release tarball with no internet access required.
Why the comparison comes up and what it gets wrong
These two tools get compared because they both speak the AWS API. If you run aws s3 ls against a LocalStack instance or against a Spinifex instance, you get the same command syntax and a similar response format. The surface-level similarity creates the impression they're doing similar things, but the underlying architecture is completely different and the appropriate use cases don't overlap.
LocalStack is optimised for speed and breadth of service coverage in a single Docker container, because those are the properties that matter for a dev inner loop. Spinifex is optimised for production reliability, real hardware management, and disconnected operation, because those are the properties that matter when the hardware you're running on is the production environment. Neither tool is trying to do what the other does.
The analogy is SQLite versus PostgreSQL. SQLite is an excellent embedded database and the right choice for a huge range of applications. PostgreSQL is a production database server designed for concurrent multi-user workloads with real persistence and replication. They both speak SQL. Choosing between them isn't really a comparison because the contexts in which each is correct don't overlap, and a benchmark between them would be measuring the wrong things.
When to use each
LocalStack is the right answer if you're writing application code against AWS APIs and you want a fast, cheap, offline-capable way to run that code in your local dev environment or CI pipeline without hitting real AWS. The free tier covers non-commercial use, and even the paid plans are inexpensive relative to the time and API cost savings for a team running hundreds of CI builds a day. If you've moved from the Community Edition and want a free alternative, Floci and MiniStack are MIT-licensed emulators that appeared in early 2026 and cover similar territory.
Spinifex is the right answer if the hardware you're running on is the production environment and you want that hardware to behave like AWS, rather than approximating AWS behaviour in a dev mock. The Terraform configs, IAM policies, CLI scripts, and SDK integrations you've written for AWS work against Spinifex without modification because the API is identical, not approximated. Spinifex is driven by operational requirements: a disconnected edge deployment, a data sovereignty obligation, or a cost calculation at scale.
Many teams run both: LocalStack or an equivalent in their dev and CI environments for the same reasons they've always used it, and Spinifex for the production edge or sovereign deployment that the real workload targets. The endpoint your application points at changes; the code doesn't.
Get started
Full Spinifex documentation is at docs.mulgadc.com, including the air-gapped installation guide for disconnected deployments. The source is on GitHub, written in Go and AGPL-3.0 licensed. Or sign up for our free sandbox to explore the API surface against a live instance before deploying on your own hardware.
Top comments (0)