fakecloud is a Rust AWS emulator with no account and no token

One binary, one endpoint, no credentials

fakecloud is described as a free, open source local AWS emulator for integration testing and local development, and the promise is unusually simple. Single binary, no account, no auth token, no paid tier. You point your AWS SDK at http://localhost:4566 and it works. The install is one command:

curl -fsSL https://fakecloud.dev/install.sh | bash   # or: brew install fakecloud
fakecloud

Then any AWS SDK or CLI talks to it with dummy credentials:

aws --endpoint-url http://localhost:4566 sqs create-queue --queue-name my-queue

The footprint is the part that makes this different from the tool it replaces. The README lists an approximately 19 MB binary, roughly 10 MiB idle, and about 300ms startup, with no Docker needed to run fakecloud itself, against a comparison figure of roughly a 1 GB image, about 150 MiB idle, 3 second start and Docker required for the LocalStack Community image it is positioned against. The performance numbers are stated as measured on Apple M1 via time fakecloud, ps -o rss and ls -lh, so they are local figures rather than a benchmark suite. For CI, where a container image is often pulled on every job, a single 19 MB binary is a different cost profile from a gigabyte image.

Why it exists: LocalStack changed its terms in March 2026

The reason for the project is stated plainly in the README. In March 2026, LocalStack replaced its open source Community Edition with a proprietary image that requires an account and auth token, and fakecloud exists so teams can keep a fully local AWS testing workflow without one. The comparison table makes the positioning concrete. Licence: fakecloud is AGPL-3.0 and free for commercial use, against proprietary paid plans. Auth: none, against account plus token. Conformance: true 100 percent with 258,545 Smithy variants, against partial. Paywalled services: none on the fakecloud side, with RDS, Cognito, SES, ElastiCache, ECS and ECR, EKS and Redshift all free, against many core services paid only. The project also positions itself as a drop-in for LocalStack in CI, with Terraform through its endpoints block, CDK through cdklocal, or any AWS SDK in any language. That compatibility claim is specific and checkable rather than a slogan, and it is what makes migration plausible.

Conformance is measured against AWS's own Smithy models

The conformance story is the most substantive claim, so it is worth describing precisely rather than repeating the number. The claim is 258,545 Smithy-model-generated test variants passing on every commit, validated against AWS's own Smithy models. The topic list on the repository confirms the intent with a parity matrix, and the repository carries the artefacts: an aws-models/ directory, a conformance-baseline.json, and conformance-baseline-notes.md. CI also runs the upstream terraform-provider-aws TestAcc suites, described as a way to catch waiter, field and drift bugs that SDK tests miss. The number is large, but the mechanism is what makes it meaningful. Generating tests from the same Smithy models AWS publishes means the cases are derived from the API definition rather than from a hand written list of what the emulator happens to implement. The coverage numbers in the README, 107 services and 7,657 operations, come with a parity matrix and per service documentation that record control plane versus data plane coverage and known limitations, which is the part to read before trusting a specific operation.

Stateful services run as real containers, not mocks

The design decision that separates this from a request-and-response mock is that stateful services get real infrastructure. Lambda supports 31 runtimes, RDS runs real Postgres, MySQL, MariaDB, Oracle, SQL Server and Db2 engines, ElastiCache runs Redis, Valkey and Memcached, and ECS and EC2 run as real containers. You can use Docker, which is the default, or native Kubernetes Pods through FAKECLOUD_CONTAINER_BACKEND=k8s, and there is a Kubernetes backend guide for that. That choice has obvious benefits, since a test that talks to a real Postgres exercises real SQL, and obvious costs, since the emulator then needs a container runtime on the machine running it. The docker-compose.yml in the repository shows the arrangement, with the fakecloud service on port 4566, the host Docker socket mounted, host.docker.internal wired for native Linux Docker, and the environment carrying FAKECLOUD_ADDR, FAKECLOUD_REGION, FAKECLOUD_ACCOUNT_ID and FAKECLOUD_LOG. The compose file also documents an opt-in EC2 security group and NACL enforcement mode that needs nftables and CAP_NET_ADMIN, and which degrades to metadata-only behaviour otherwise.

Test SDKs that assert on calls instead of HTTP

The first-party SDKs are what turn an emulator into a test harness. They exist for TypeScript, Python, Go, PHP, Java, Rust and .NET, and the stated value is that you can assert on what your code called without raw HTTP. That distinction matters. An endpoint returning 200 tells you the request was accepted, while a test SDK records the call your application made, its parameters and its outcome, which is what you want to assert when the thing under test is the interaction with AWS rather than the response handling. The README contrasts this with the LocalStack Community image, which lists first-party SDKs for Python and Java only. The repository has an sdks/ directory for them, and a set of examples covering node, python, terraform, a sample app and a docker-compose arrangement. The emulator itself is also designed to run an existing application unmodified, since the AWS SDK default credential chain can resolve an instance or task role against fakecloud with no static keys and no code change, by pointing AWS_CONTAINER_CREDENTIALS_FULL_URI at the credentials endpoint.

URL compatibility, signature checks and IAM as opt-ins

Two design choices exist to make migration painless and to make the default posture convenient. The first is host header routing, where both *.localhost.localstack.cloud and *.amazonaws.com host headers route correctly, including every S3 virtual-hosted variant, so persisted URLs and dev scripts from either system replay unchanged. The second is that security enforcement is off by default. SigV4 verification is available through a --verify-sigv4 flag, and IAM evaluation through --iam soft|strict for policy evaluation across IAM, STS, SQS, SNS, S3, KMS, Lambda, DynamoDB and its Streams, ELBv2 and Scheduler. The stated reason for the default is that tests just work. The tradeoff is that by default your code is not actually signing correctly and your IAM policies are not actually enforced, so a test suite can pass while the production configuration would fail. If you are using this to validate an application's AWS integration rather than its logic, turning both on is the more honest configuration, and the security reference documentation is where the details live.

The Bedrock surface and the AI testing angle

The Bedrock support is the largest single feature in the list and the one with the clearest testing use case. The README describes a full Bedrock surface of 222 operations across 4 APIs, with real InvokeModel and Converse streaming, guardrails, agents and flows, and configurable responses plus fault injection for deterministic tests. Fault injection is the part that matters for testing, because it lets you make a model call fail in a controlled way and assert on your retry and error handling, which is otherwise hard to reproduce against a real endpoint. The repository carries a dedicated bedrock-emulator directory, and the crate workspace reflects the granularity, with separate crates for fakecloud-bedrock, fakecloud-bedrock-agent and fakecloud-bedrock-agent-runtime alongside a fakecloud-conformance crate and its macros and checksum helpers. The topic list on the repository names ai-testing, llm-testing, aws-bedrock and bedrock-emulator, so this is a deliberate direction rather than a single service implementation.

Where the emulator stops, and what to check first

The boundaries are documented rather than hidden, but they need reading. fakecloud is an emulator, and it says so: it is not AWS, so behaviour that depends on the real service is not reproduced, and the per service documentation lists known limitations alongside the operation counts, so the parity matrix is the document to consult for your specific calls. The workspace in Cargo.toml shows the granularity of the implementation, one crate per service family including account, amplify, apigateway, batch, cloudformation, cognito, dsql, ecs, eks, glue, iam, kinesis and many more, which tells you the surface is broad but also that each service is a separate module with its own state. There is also a resource cost. Even though fakecloud itself needs no Docker, the services that run real containers need a container runtime, so a CI runner that wanted to avoid Docker will find that requirement returns through the Lambda, RDS and ElastiCache paths. The licence is AGPL-3.0, which is the one legal detail to confirm before you embed it in a commercial product, and the release history is fast, v0.51.0 on 2026-10-18 with v0.50.0 and v0.49.0 on 2026-10-06, with the last push on 2026-10-19.

Editorial conclusion

Adopt fakecloud when your tests need to reach AWS shaped APIs without credentials, a paid tier or a container image, and when you want the same endpoint URL and SDK calls to work in CI as on a developer machine. Do not adopt it expecting a production AWS substitute or a complete service surface, since the parity matrix lists per service limitations and the emulator is not AWS itself. Verify first that the services and operations your code calls are marked covered in the parity matrix, that your container platform can run the backing containers for Lambda, RDS, ElastiCache and ECS, and that the SigV4 and IAM checks you enable match what your application actually signs.

Frequently asked questions

Official sources

1. faiscadev/fakecloud on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases