Fakecloud and Spinifex both answer to the AWS API, which is enough to land them in the same search results. They are not alternatives to each other. Fakecloud covers local development and CI. Spinifex covers production when that environment is hardware you own. Knowing which is which keeps a dev tool out of production and a production platform out of your CI pipeline.
What Fakecloud is
Fakecloud is a free, MIT-licensed AWS emulator built around the AWS Smithy service models. Instead of hand-writing each service, it generates its API surface from the same models AWS publishes, and that is how it reaches 105 services and 7,396 operations. The breadth is the point: model-driven coverage rather than hand-tuned depth.
The runtime is a single binary of around 19 MB that idles near 10 MiB, so it fits into a CI job or a laptop without much overhead. Covered services include S3, DynamoDB, SQS, Lambda, IAM, STS, ECS, ECR, EC2, and Bedrock, plus RDS backed by six real database engines and 80 more beyond those. The project is younger and smaller by star count than Floci or LocalStack, and it targets a wider slice of the API than either.
Fakecloud does not run real infrastructure. Call ec2 run-instances and you get a well-formed response that matches the model, but no virtual machine boots. Call s3 put-object and the bytes land somewhere convenient for the test, with no erasure-coded storage engine enforcing durability. For an emulator that trade-off is correct, because a developer's inner loop and a CI job need fast, faithful responses rather than production behaviour under load.
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 a virtual machine through QEMU. S3 objects go to Spinifex's built-in object store, which spreads them across nodes with Reed-Solomon erasure coding. IAM policies evaluate against real principals and enforce across real network boundaries.
Spinifex is built for production where AWS itself is unavailable: disconnected field deployments, air-gapped secure facilities, and data sovereignty rules that forbid sending data to infrastructure outside your control. It runs with no external control plane, makes no phone-home call, and installs from a release tarball with no internet access. The AWS CLI, Terraform with the AWS provider, eksctl, and any AWS SDK work against it with a single endpoint override.
Why these two get compared
Both tools answer aws s3 ls correctly, and Fakecloud's model-driven conformance means it answers a long list of other calls too. That breadth is what surfaces it next to Spinifex when a team searches for a way to run the AWS API off Amazon. The choice comes up whenever a team replacing LocalStack is also weighing where production will run.
Conforming to the API model and provisioning real infrastructure are different jobs. Fakecloud checks that your requests are well-formed and that your code handles the responses. Spinifex runs the workload. A suite that passes against Fakecloud tells you the integration code is correct. It does not tell you the VM will boot, the volume will survive a lost node, or the policy will deny the call it should deny.
How they fit together
Plenty of teams run both, at different stages of one pipeline. Fakecloud sits in development and CI, giving engineers a broad, quick AWS surface to build against with no account and no bill. Spinifex sits in production when that production is hardware the team controls, serving the same AWS API the application was written against.
The endpoint changes between stages. The application code does not. Teams whose production target is AWS finish with a validation pass on real AWS. Teams whose production target is their own hardware finish on Spinifex: the same API, running on the machines that are the production environment.
Get started
Fakecloud is at github.com/faiscadev/fakecloud, MIT-licensed and needing no account to run. Spinifex documentation, including the air-gapped installation guide for disconnected deployments, is at docs.mulgadc.com. 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)