fakecloud: Free LocalStack Alternative for AWS Tests
fakecloud is a free, open-source (AGPL-3.0) single-binary AWS emulator: point your AWS SDK or CLI at http://localhost:4566 and it emulates 105 services and 7,500+ operations. It emerged after LocalStack replaced its Community Edition with an account-and-token-gated image in March 2026. This guide covers installation, usage, and how it compares to LocalStack, MiniStack, floci, and Moto, based only on the official README and docs. Updated Sep 2026.
fakecloud is a free, open-source (AGPL-3.0) single-binary AWS emulator: point your AWS SDK or CLI at http://localhost:4566 and it emulates 105 services and 7,500+ operations locally. No account and no auth token are required, so it drops straight into existing AWS integration tests in CI and local development.
It's built by faiscadev (a GitHub organization). The repository was created on April 4, 2026, and as of this writing (September 28, 2026) has 702 stars and 47 forks — a young project that just hit the front page of Hacker News (105 points) this week. The latest release is v0.45.1. This article is based only on the official README (github.com/faiscadev/fakecloud) and the official site (fakecloud.dev): why it exists, what it does, how to install and use it, and how it compares to other tools.
Why it's getting attention now — LocalStack's policy change
The trigger was March 2026, when LocalStack changed the localstack:latest image so that even the free Community Edition required an account and an auth token. CI pipelines that ran without a token broke overnight, and many core services — RDS, Cognito, SES v2, ElastiCache, API Gateway, ECR, and real Lambda code execution — moved behind the paid LocalStack Pro tier. fakecloud's README positions the project directly against this shift: "fakecloud exists so teams can keep a fully local AWS testing workflow without one" (an account or token). The same episode also fueled rapid adoption of other free alternatives such as MiniStack, floci, and Moto.
What it can do
The README's central claim isn't just mocked responses — it's fidelity to how AWS actually behaves. CI runs 248,557 Smithy-model-generated test variants on every commit, claimed as true 100% conformance against AWS's own Smithy models. It also runs upstream terraform-provider-aws TestAcc* suites in CI, said to catch waiter and field-drift bugs that plain SDK tests miss.
| Feature | Details | |
|---|---|---|
| Service coverage | 105 services, 7,509 operations. Highlights: S3, DynamoDB, SQS, SNS, EventBridge, Lambda, IAM, STS, KMS, Secrets Manager, CloudFormation, SES, Cognito, Kinesis, RDS (6 engines), ElastiCache, ECS/ECR, EC2, Step Functions, API Gateway v1/v2, Bedrock, and 80+ more | |
| Real infra for stateful services | Lambda (23 runtimes), RDS (Postgres/MySQL/MariaDB/Oracle/SQL Server/Db2), ElastiCache (Redis/Valkey/Memcached), ECS, and EC2 run as real containers via Docker (default) or native Kubernetes Pods (FAKECLOUD_CONTAINER_BACKEND=k8s) | |
| Cross-service wiring | EventBridge -> Step Functions, S3 -> Lambda, SES inbound -> S3/SNS/Lambda, and 15+ more integrations execute end-to-end | |
| Bedrock support | 216 operations across 4 APIs, with real InvokeModel/Converse streaming, guardrails, agents, and flows; configurable responses and fault injection for deterministic tests | |
| Footprint | ~19 MB single binary, ~10 MiB idle, ~300ms startup (measured on Apple M1), no Docker needed to run fakecloud itself | |
| Auth / security | SigV4 verification and IAM enforcement are off by default so tests just work; --verify-sigv4 and `--iam soft\ | strict` opt in across IAM, STS, SQS, SNS, S3, KMS, Lambda, DynamoDB (and Streams), ELBv2, and Scheduler |
| Unmodified apps | An app expecting an instance/task role resolves the AWS SDK default credential chain against fakecloud with no static keys and no code change, by pointing AWS_CONTAINER_CREDENTIALS_FULL_URI at /_fakecloud/credentials | |
| URL compatibility | Both *.localhost.localstack.cloud and *.amazonaws.com Host headers route correctly, including every S3 virtual-hosted variant, so persisted URLs and scripts written for LocalStack or real AWS replay unchanged |
First-party test SDKs — assert side effects directly
Application code keeps using a normal AWS SDK; only the test code switches to fakecloud's own test SDK. It supports seven languages — TypeScript, Python, Go, PHP, Java, Rust, and C#/.NET — letting tests assert things like "exactly one email was sent" or "Lambda was invoked with these arguments" without parsing raw HTTP responses.
import { FakeCloud } from "fakecloud";
const fc = new FakeCloud();
// Your app sends through the normal AWS SDK.
// Your test asserts the side effect directly.
const { emails } = await fc.ses.getEmails();
expect(emails).toHaveLength(1);
await fc.reset();Installation and pricing
| Item | Details |
|---|---|
| Publisher | faiscadev (GitHub organization, repo created 2026-04-04) |
| License / pricing | AGPL-3.0 open source, free, no account, no paid tier |
| Implementation | Single binary written in Rust |
| Latest version | v0.45.1 |
| Install options | Official install script, Homebrew, Cargo, npm, or Docker (ghcr.io/faiscadev/fakecloud) |
| Docs | fakecloud.dev/docs |
| README note on licensing | "Using fakecloud as a dev/test dependency has zero AGPL implications for your application" |
The fastest path is the install script; Homebrew, Cargo, npm, and Docker are also supported.
curl -fsSL https://fakecloud.dev/install.sh | bash # or: brew install fakecloud
fakecloud # starts on http://localhost:4566Usage — the shortest path
- Start fakecloud: run fakecloud and it listens on http://localhost:4566
- Point your AWS SDK or CLI at it: use dummy credentials (access_key=test, secret_key=test) and set --endpoint-url (or Terraform's endpoints block, or CDK's cdklocal) to localhost:4566
- Write and run code as usual: your application keeps using a plain AWS SDK to create and call S3 buckets, SQS queues, Lambda functions, and so on
- Verify side effects with the test SDK: assert sent emails, SNS messages, or Lambda invocations directly through fakecloud's own test SDK
- Opt into SigV4/IAM enforcement if needed: add --verify-sigv4 and --iam soft|strict to layer in production-like authorization checks incrementally
aws --endpoint-url http://localhost:4566 sqs create-queue --queue-name my-queueFor CI setups, Terraform/CDK integration, and running the Kubernetes container backend, the fakecloud.dev/docs/getting-started guide is the source of truth. For the broader mindset of wiring tests into CI/CD, see our guides on Flutter testing and CI/CD and React Native testing strategies.
How it differs from existing tools
| fakecloud | LocalStack Community (post-March 2026) | floci | Moto | |
|---|---|---|---|---|
| License / pricing | AGPL-3.0, free, no account | Proprietary, requires account + auth token, many core services paid-only | MIT, free | Apache-2.0, free |
| Implementation | Single Rust binary (no Docker required) | Docker image (~1 GB) | Java (Quarkus Native), with Docker Compose / Testcontainers support | Python library (in-process mocking, no server) |
| Service scale | 105 services, 7,509 operations | Broad but many core services now paywalled | 47 services | Broad surface, varying depth |
| Lambda execution | Actually runs in real Docker/K8s containers (23 runtimes) | Only on certain paid plans | Runs Lambda in real containers too | Does not execute code — mocked responses only |
| Startup / footprint | ~19 MB binary, ~10 MiB idle, ~300ms start | ~1 GB image, ~150 MiB idle, ~3s start | ~13 MiB idle, ~24ms start | In-process Python, no standing server |
| Test-assertion SDKs | TypeScript, Python, Go, PHP, Java, Rust, .NET (7 languages) | Python, Java only | Testcontainers modules for Java, Node.js, Python | Called directly from each language's own test framework (no dedicated assertion SDK) |
| Best fit | Teams that want CI/local integration tests to stay faithful to real AWS behavior, for free | Teams that value commercial support and a mature ecosystem and can accept the paid tier | Teams that want many services in real containers plus very fast startup | Python unit tests that want lightweight AWS mocking without needing real Lambda execution |
LocalStack still leads on community assets and commercial support even after its March 2026 policy change, but the account-and-token requirement is now a real operational hurdle for teams that want to stay free. MiniStack and floci emerged from the same episode, but fakecloud's own comparison page explicitly says MiniStack's exact specs "move fast" and recommends checking each repo directly rather than trusting side-by-side numbers. floci is written in Java (Quarkus Native), covers 47 services, and leans on startup speed (~24ms) as its differentiator. Moto is the longest-running open-source AWS mocking library (Python), valued for its lightweight in-process patching, but it does not actually execute Lambda code. For related background, see our guides on comparing S3, R2, Azure Blob, and GCS and AWS basics for SMBs.
Migration notes and who it's for
- fakecloud.dev describes migrating from LocalStack as swapping one Docker image line, but teams should still audit every place an endpoint URL and credentials are configured across a project
- AGPL-3.0 is a strong copyleft license, but the README explicitly states that using fakecloud as a dev/test dependency carries zero AGPL implications for your own application; check the license terms carefully if you modify or redistribute fakecloud itself in production
- IAM and SigV4 checks are off by default, so teams that want to catch permission bugs before production should adopt a deliberate policy of enabling --iam strict and similar flags
- For products testing generative AI features via Bedrock, fault injection and configurable fixed responses help build deterministic tests
- Per-service limitations and unimplemented operations are documented on the parity page (fakecloud.dev/docs/parity) — check your own team's must-have services before migrating
- Best suited for teams that want to keep AWS integration tests free and token-free in CI and local development, especially those directly affected by LocalStack's paywall
FAQ
Is fakecloud free to use?
Yes. It is open source under AGPL-3.0, requires no account or auth token, and has no paid tier. The README explicitly states that using it as a dev/test dependency carries zero AGPL implications for your own application.
Is migrating from LocalStack difficult?
The official site describes it as roughly a one-line Docker image swap, since endpoint URLs and credential configuration are shared between the two. Still, teams should audit every place these are configured in their own project.
Is Docker required?
No — fakecloud itself runs as a single binary with no Docker needed. Docker (the default) or Kubernetes Pods (FAKECLOUD_CONTAINER_BACKEND=k8s) are only needed for real stateful backends like Lambda, RDS, ElastiCache, ECS, and EC2.
Which languages have official test SDKs?
TypeScript, Python, Go, PHP, Java, Rust, and C#/.NET — seven languages in total.
Are IAM and SigV4 verification enabled by default?
No, both are off by default so tests work without extra configuration. --verify-sigv4 enables real signature checking, and --iam soft|strict enables IAM policy evaluation across IAM, STS, SQS, SNS, S3, KMS, Lambda, DynamoDB (and Streams), ELBv2, and Scheduler.
How is it different from MiniStack or floci?
All three emerged after LocalStack's March 2026 policy change. fakecloud emphasizes depth — 105 services, 7,509 operations, and a claim of true 100% Smithy conformance. floci is written in Java (Quarkus Native), covers 47 services, and emphasizes a ~24ms startup time. MiniStack's exact specs are described by fakecloud's own comparison page as changing quickly, so checking its repository directly is recommended.
Summary
fakecloud is a free, open-source AWS emulator that emerged directly in response to LocalStack Community Edition's move to a paid, account-gated model. As a single binary with no account required, it emulates 105 services once you point an AWS SDK or CLI at localhost:4566, and services like Lambda, RDS, and ECS actually run as real containers rather than returning mocked responses.
The seven-language test SDKs — for asserting side effects like sent emails or Lambda calls directly — and the opt-in, incremental IAM/SigV4 enforcement make it practical for teams that want integration tests to stay close to real AWS behavior. A reasonable first step is installing it locally and running an existing LocalStack-targeted test suite against it unchanged.
References (primary sources)
Related free tools (no sign-up, instant results)
Feel free to contact us
Contact Us