The fake cloud is becoming a serious tool.
Floci presents local emulators for AWS, Azure, Google Cloud, and Oracle Cloud. Its AWS project is MIT licensed and uses the same port, 4566, that many LocalStack setups use. The project says its current AWS build covers 119 services. That number and the performance figures on its site are vendor claims.[1]
There is a real artifact behind the page. We pulled the published floci/floci:2.1.0 image by digest, started it on an isolated local port, and received HTTP 200 from its health endpoint. The response identified version 2.1.0 and listed its service states. That smoke check proves the published container started here. It does not verify 119 services or production compatibility.
LocalStack remains another established route. Its current installation documentation says LocalStack for AWS features require an auth token. The documentation recommends its lstk command for local startup and also documents Docker Compose, Docker, and Helm routes.[2] Tool choice can depend on service coverage, licensing, authentication, CI fit, and the exact behavior your application needs.
A local emulator can remove cloud credentials from the agent loop. It cannot remove the need for a production-shaped test.
Endpoint compatibility is the first clamp.
A client can point at localhost:4566, create a bucket, and pass a happy-path test. That is useful. It confirms that the client, configuration, request shape, and local service can complete that path.
It says less about service limits, permission edges, event timing, regional differences, managed-service defaults, or failure behavior. Even projects that run real PostgreSQL, Redis, or Kafka engines still implement a control plane around those engines. The provider remains a different system.
Testcontainers gives a good mechanical pattern for the local half. Its LocalStack guide starts an ephemeral container on a random available port so parallel CI jobs do not collide. The example routes SQS messages into S3 and asserts the resulting object through the application.[3] The important move is not the product name. The test owns the emulator lifecycle, receives a fresh endpoint, and checks an application outcome.
Failures need their own lane.
Happy-path emulation is easy to overvalue because it is fast and visible. Production systems also throttle, drop connections, delay events, reject permissions, and partially complete work.
AWS Prescriptive Guidance lists throttling, temporary network loss, and temporary service unavailability as transient failures that may need retry with backoff. It also warns that retried operations should be idempotent. Otherwise, partial updates can corrupt state.[4]
Do not wait for a staging incident to find out whether the generated retry loop duplicates work. Inject a throttling response. Drop a connection after the write. Delay the queue message. Repeat the request with the same idempotency key. The emulator may support some of these tests. A proxy or application seam can provide the rest.
Use two loops, not one badge.
- Local loop. Run the emulator without real cloud credentials. Check request shape, application flow, state changes, and cleanup on every useful change.
- Provider contract. Compare the provider behavior your application depends on. Keep a list of unsupported or simplified emulator behavior.
- Failure drill. Exercise throttling, delay, retry, duplicate delivery, and interrupted writes where they matter.
- Live canary. Run one narrow test in a disposable real-cloud account with a spend cap, scoped credentials, and automatic teardown.
The live canary should be smaller than the local suite. Its job is to detect drift between the doppelganger and the provider. It should not give an agent broad standing access to a shared account.