Floci and Spinifex both implement the AWS API surface, and that surface-level similarity puts them in the same search results. They're not alternatives to each other. Floci covers local development and CI. Spinifex covers production when that environment is hardware you own. Understanding why helps you use both without expecting either to do the other's job.
What Floci is
Floci is a free, open-source AWS emulator built to replace LocalStack Community Edition after LocalStack archived its free tier in March 2026. It's built on Quarkus and compiled to a native binary via GraalVM, which produces its headline numbers: startup time around 24ms and idle memory around 13 MiB. It covers 47 AWS services, requires no account or auth token, and is MIT-licensed.
The design intention is explicit drop-in compatibility. Floci listens on port 4566 and accepts the same credential pattern as LocalStack, so existing SDK configurations, Docker Compose setups, and CI scripts work without changes. It also translates LocalStack environment variables automatically for teams migrating from older configurations. Beyond AWS, it supports Azure and GCP endpoints, which is useful for codebases that target more than one cloud provider.
What Floci doesn't do is run real infrastructure. When your code calls s3.put_object, Floci intercepts that call and stores the data somewhere convenient for the test. There's no actual storage engine enforcing durability guarantees, no real IAM policy evaluation against a real principal, and no hypervisor managing virtual machine state. That's the correct trade-off for a development tool: speed and breadth of service coverage matter more than production-grade correctness when you're running a developer's inner loop or a CI job.
What Spinifex is
Spinifex is an AWS-compatible cloud platform for hardware you own. It implements EC2, S3, IAM, EKS, and the rest of the common AWS service surface on standard Linux bare metal, and the implementation is real: an aws ec2 run-instances call provisions an actual virtual machine using QEMU. S3 objects go to Predastore, which distributes them across nodes using Reed-Solomon erasure coding. IAM policies are evaluated against real callers and enforced across real network boundaries.
The use cases are production environments where AWS itself isn't available: disconnected field deployments, air-gapped secure facilities, and data sovereignty requirements that prohibit sending data to infrastructure outside your direct control. Spinifex runs without any external control plane, has no phone-home requirement, and installs from a release tarball with no internet access needed. The AWS CLI, Terraform with the AWS provider, eksctl, and boto3 all work against it with a single endpoint override.
Why these two get compared
Both tools answer aws s3 ls correctly. That's enough to surface both in the same search, and the question "should I use Floci or Spinifex?" comes up whenever a team with existing LocalStack infrastructure is evaluating on-premise options at the same time.
The architecture underneath is completely different, and the appropriate contexts don't overlap. Floci is optimised for startup time, low resource footprint, and broad service coverage in a container, because those are the properties that matter in a developer's inner loop. Spinifex is optimised for production reliability, real hardware management, and disconnected operation, because those are the properties that matter when bare metal is the production environment.
A benchmark between them would measure the wrong things. Floci starts in 24ms; Spinifex starts VMs on real hardware. Floci fits in a Docker container; Spinifex manages your infrastructure. Neither is trying to do what the other does.
How they fit together
Many teams use both across different stages of the same pipeline. Floci runs in the development environment and CI so that engineers can write and test code against AWS APIs without a cloud account or a cloud bill. Spinifex runs in the production environment when that environment is hardware the team controls, and provides the same AWS API surface that the application was developed against.
The endpoint changes between stages. The application code doesn't.
Get started
Floci is at github.com/floci-io/floci, MIT-licensed and requiring no account to run. Documentation for Spinifex 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 the free sandbox to explore the AWS-compatible API surface before deploying on your own hardware.
Top comments (0)