For the better part of a decade, LocalStack was the default answer to a persistent developer problem: how do you write and test code that calls AWS APIs without running up a cloud bill on every CI job? The answer was a local daemon on port 4566 that emulated enough of the AWS surface to keep your tests green, and for most teams it worked well enough that they stopped thinking about it. That changed on March 23, 2026, when LocalStack archived its Community Edition GitHub repository and announced that running the emulator for commercial purposes would require a paid account. The developer community responded quickly, and a handful of capable free alternatives emerged within weeks.
This is a survey of those alternatives, what each one does well, and where the emulator model runs into its inherent limits.
What happened to LocalStack Community Edition
LocalStack's changes were more nuanced than a simple on/off switch. The Community Edition repository was archived and made read-only, and from that point forward LocalStack ships a single image via Docker Hub that requires an account and an auth token to run. A non-commercial free tier remains available for individual developers experimenting for personal use, and open source projects can apply for free access to the paid plan. Commercial use, including CI pipelines, requires a paid subscription.
The backlash was significant because many teams had built CI infrastructure around localstack/localstack:latest and found their pipelines broken when the commercial restriction kicked in. The move made business sense for a company that had invested years in building out hundreds of service emulations, but it left a real gap in the open source tooling landscape, and that gap attracted several responses.
Floci: fast, free, and MIT-licensed
Floci emerged directly in response to LocalStack's commercialisation. It's built on Quarkus and compiled to a native binary via GraalVM, which accounts for its headline numbers: startup in around 24ms and idle memory usage of roughly 13 MiB. It covers 47 AWS services, requires no auth token or account, and is licensed under MIT.
The design goal is explicit drop-in compatibility with LocalStack. The same port (4566), the same credential pattern, and the same SDK configuration all work without changes, and Floci translates LocalStack environment variables automatically for teams migrating from the older setup. It also supports multiple cloud providers beyond AWS, including Azure and GCP, which is useful for teams writing code that targets more than one cloud.
Floci's native compilation means it adds almost nothing to container startup time, which matters for teams running many short-lived CI jobs. The trade-off is that it covers fewer services than LocalStack's paid tier, so teams that relied on the full breadth of LocalStack Pro will find some gaps.
MiniStack: real infrastructure backing some services
MiniStack takes a different approach to the same problem. Where Floci and LocalStack both emulate AWS service behaviour in-process, MiniStack backs some services with real infrastructure: when your test code writes to its mock RDS endpoint, a real PostgreSQL instance is handling the storage. The same applies to services like ElastiCache, which MiniStack backs with a real Redis instance.
This means better fidelity for database-heavy tests, because you're testing against a real query engine rather than a mock that might handle edge cases differently. The trade-off is a heavier footprint: the Docker image is around 270 MB and idle memory usage is roughly 30 MB, compared to Floci's 13 MiB, though startup is still under two seconds. MiniStack is MIT-licensed, Python-based, runs on port 4566, and covers 60+ services with no account required.
For teams whose biggest testing risk is database behaviour rather than AWS API surface coverage, MiniStack's real-infrastructure approach reduces the gap between what tests exercise and what production runs.
Moto: in-process mocking for Python
Moto is a different category of tool. It's not a daemon you run in Docker; it's a Python library that intercepts boto3 calls in-process, so your tests never make a network request at all. You decorate a test function with @mock_aws, and any boto3 calls within that function are handled by Moto's in-memory implementations.
Moto is the fastest option: no container startup, no network round trip. It's also the simplest to set up for Python-only codebases. The limitation is that it's Python-specific and only useful for unit testing individual functions or modules. If you need to test a service that calls other services, or a CI job that runs actual CLI commands against a local endpoint, you need a daemon-based tool like Floci or MiniStack instead.
What all emulators share in common
The tools above work well for teams who need to test AWS-dependent code without cloud access. They all operate within the same fundamental constraints, though.
An emulator mocks the AWS API surface. When your code calls s3.put_object, something intercepts that call and stores the data somewhere convenient. What doesn't happen is a real storage engine enforcing real durability, a real IAM policy evaluation engine checking the actual caller's permissions, or a real EC2 hypervisor managing virtual machine state. The mock stores just enough to make your code behave correctly in the common case, which is exactly what you need for a unit test and exactly what falls short when correctness at the margins matters.
In practice, this means there are categories of bug that emulators can't catch: IAM permission errors that only surface when a real policy evaluation is applied to a real principal, storage behaviour under concurrent writes, and EC2 lifecycle events that depend on the actual state of a running VM. These aren't criticisms of the emulators because finding those bugs isn't what they're for. They're optimised for speed and convenience in development, not for production parity.
When the production target is bare metal
The emulator model assumes that the eventual production target is real AWS. The mock is a convenience layer for development and CI, and the expectation is that final validation happens against the actual cloud.
For teams whose production environment is hardware they own and operate rather than an AWS region, the gap between emulator and production is structural. There's no "real AWS" to validate against; bare metal is the real environment.
Spinifex is the AWS-compatible cloud platform built for that case. It runs on standard Linux bare metal hardware and implements the AWS API surface, covering EC2, S3, IAM, EKS, and the rest of the common services, with real VM management, real block storage persistence, real IAM policy enforcement, and real network isolation between workloads. The endpoint your AWS CLI, Terraform, and SDKs talk to is different, but the API they're calling behaves the same way it does in AWS, including at the margins that emulators smooth over.
Emulators and Spinifex sit at different stages of the same pipeline. Floci or MiniStack covers local development and CI. Spinifex covers production when that environment is hardware you control, keeping the AWS toolchain intact for teams in air-gapped facilities, sovereign deployments, or edge environments where cloud connectivity isn't available or isn't permitted.
Get started
Floci is at github.com/floci-io/floci and MiniStack is at ministack.org. Documentation for Spinifex, including the air-gapped installation guide and Terraform workbooks, is at docs.mulgadc.com. The source is on GitHub, written in Go and AGPL-3.0 licensed. Or sign up for our free sandbox to explore the API before deploying on your own hardware.
