Why I'm building a free, open-source AWS emulator

Unknown — Mon, 06 Apr 2026 00:00:00 +0000

A few days ago, our CI started failing. The culprit: localstack:latest</code> now requires an account and an auth token. Broken builds.

I'd seen LocalStack creeping toward proprietary for a while, but this was the moment it actually hit. A colleague noticed it at the same time as me, but I was already working on a fix. I patched the build, but the question stuck: how long can we keep using the old version until we start having real problems?

I don't trust mocks</h2> I should back up. I care about tests a lot. Enough to become a maintainer of Chai.js</a>. Enough that when I build something, the test infrastructure comes first. But I have a specific opinion about what kind of tests matter. I hate mocks. Not the concept — the way most codebases use them. You end up with tests that don't test anything real. You're asserting that you call functions in the right order. You're verifying the plumbing, not the behavior. The worst part is when mocked tests give you false confidence. I've seen tests that assert you do the wrong thing successfully — the mock doesn't care, it just returns what you told it to. Your tests pass. Your code has a bug. You ship it. If you're building on AWS, you need integration tests that actually talk to something that behaves like AWS. Not a mock. Not a stub that returns 200 to everything. Something that implements the real behavior: if you call API A then API B, and AWS would produce side effect C, then your test environment should produce side effect C too. That's what LocalStack used to give us. And that's what I wanted to keep — but free and open source. So I built it</h2> I started fakecloud on April 4th, 2026. Three days later: 13 AWS services, 300+ commits, 1,000+ tests. That pace was possible because of two things. First, I used LLMs heavily throughout — not to generate code I don't understand, but as a force multiplier with strong guardrails. Every feature ships with E2E tests. The tests are the guardrails. If the LLM generates something that doesn't match real AWS behavior, the tests catch it. Second, Rust. I chose Rust because I love static-typed compiled languages, and Rust's type system is genuinely amazing. You get the performance of no garbage collector without having to manually manage memory. It means fakecloud starts in under 100ms and runs as a single binary — no Docker required, no runtime dependencies. Correctness is the whole point</h2> fakecloud doesn't try to be a scalable production cloud. It's not that. It's a testing tool. And the one thing a testing tool needs to get right is correctness. What does that mean in practice? If you call CreateQueue</code>, then SendMessage</code>, then ReceiveMessage</code> on real AWS and get back your message with specific attributes — fakecloud should do exactly the same thing. If it doesn't, that's a fakecloud bug. We currently verify this with 280+ E2E tests that use the official aws-sdk-rust</code> crate and 34,856 auto-generated conformance test variants validated against official AWS Smithy models — covering all 731 API operations across 13 services at 100% conformance. The plan for the near future: set up a real AWS account and run our test suite against both fakecloud and real AWS side by side, so we can verify behavioral parity automatically. What's here today</h2> 13 services, 731 API operations, all open source, all free: S3 (74 actions) — objects, multipart uploads, versioning, lifecycle, notifications, encryption</li> SQS (20 actions) — FIFO queues, dead-letter queues, long polling, batch operations</li> SNS (34 actions) — fan-out to SQS, HTTP delivery, filter policies, platform applications</li> EventBridge (57 actions) — pattern matching, scheduled rules, connections, API destinations, endpoints</li> IAM (128 actions) — users, roles, policies, groups, instance profiles, OIDC/SAML providers</li> STS (8 actions) — assume role, session tokens, federation</li> SSM (146 actions) — parameters, documents, commands, maintenance windows, associations, automation, sessions</li> DynamoDB (57 actions) — tables, items, transactions, PartiQL, backups, global tables, streaming</li> Lambda (10 actions) — function CRUD, invoke, event source mappings</li> Secrets Manager (23 actions) — versioning, soft delete, rotation, replication, resource policies</li> CloudWatch Logs (113 actions) — groups, streams, filtering, deliveries, transformers, anomaly detection</li> KMS (53 actions) — encryption, aliases, key management, grants, custom key stores</li> CloudFormation (8 actions) — template parsing, resource provisioning</li> </ul> Services talk to each other: S3 notifications deliver to SNS/SQS. SNS fans out to SQS. EventBridge rules fire on schedule and deliver to targets. This is the kind of cross-service behavior that matters in integration tests and that most emulators get wrong or skip entirely. Try it</h2> curl -fsSL https://raw.githubusercontent.com/faiscadev/fakecloud/main/install.sh | bash fakecloud</code></pre> Then point any AWS SDK at http://localhost:4566</code> with dummy credentials. That's it. The code is at github.com/faiscadev/fakecloud</a>. It's AGPL-3.0 — free and open source, including for commercial use. If you need a local AWS emulator for your integration tests, give it a try. And if something doesn't behave like real AWS — open an issue</a>. That's a bug, and we'll fix it.