An engineer needs a cloud account to test a change. Another engineer is already using it. Someone updates a shared resource, a test fails, and the team spends the afternoon determining whether the problem lies in the code or the environment.
Meanwhile, resources left running between test runs continue to add to the bill.
These are familiar problems in cloud development. They are also part of the reason I created Awesome Cloud Emulators: a curated list of cloud emulators and supporting tools for local development and automated testing.
My aim is to make it easier to discover the available options, understand their boundaries, and choose something that fits the work you need to do.
Bring more of the feedback loop closer to engineers
Cloud emulators reproduce selected cloud service APIs and behavior locally. Depending on the tool, you might run one as a container, a standalone server, or an in-process dependency in your tests.
That can give you a dedicated environment to check application interactions with storage, queues, databases, and other supported services. You can create test resources, exercise a workflow, and clean up without coordinating every change through a shared cloud account.
There is a cost benefit too. Moving suitable development and CI workloads locally can reduce repeated provisioning, idle cloud resources, and billable service calls. The savings depend on the workload: local compute, maintenance, and any software licensing still have costs.
For me, the useful question is: which checks can we run earlier, more often, and with less setup?
What you will find in the repository
The list covers AWS, Microsoft Azure, Google Cloud and Firebase, Oracle Cloud, Cloudflare, Snowflake, and tools spanning multiple providers, including European cloud providers.
It separates broader suites from tools focused on individual services. A few examples illustrate the range:
| Area | Examples in the list | Focus |
|---|---|---|
| AWS | Moto, ElasticMQ, S3Mock | AWS API mocking, SQS-compatible messaging, and selected S3 operations |
| Azure | Azurite, Azure Key Vault Emulator | Local storage and Key Vault client testing |
| Google Cloud and Firebase | Firebase Local Emulator Suite, Fake GCS Server, Spanner Emulator | Local Firebase workflows and selected storage or database APIs |
| Cloudflare | Miniflare | Local Workers simulation and supported storage bindings |
| European providers | Feint | API emulation for Scaleway, Outscale, and Exoscale |
These examples are starting points to investigate. Each entry links to upstream documentation so you can check the operations and requirements that matter to your application.
The repository also includes a selection guide with scenario-based shortlists, a comparison of the entries, and an evaluation checklist.
The supporting tools matter too
An emulator is only one part of a local development workflow. You still need to start it, connect your application, prepare data, and manage its lifecycle.
The supporting tools section includes:
- Testcontainers integrations for managing supported emulator containers from tests.
- AWS SAM CLI, Azure Functions Core Tools, and Serverless Devs for local function development and execution.
- Toxiproxy for injecting network latency and connection failures between an application and an emulator.
- Moto Recorder for recording and replaying requests to rebuild test baselines.
- CRIU, DMTCP, and container checkpoint tools for exploring capture and restore of prepared environments, subject to compatibility checks.
These tools have different roles. A local function runner does not automatically emulate the services the function calls, and request replay is different from restoring process memory. The descriptions make those distinctions explicit.
Choose based on your test scenario
Before choosing a tool, write down the workflow you need to validate.
For example: an application writes an object, publishes a message, and a worker processes it. That gives you a concrete set of operations and interactions to evaluate.
Then check:
- Does the emulator support the API operations your application uses?
- Does it work with your SDK or IaC provider version?
- Can each test or worker have isolated state?
- How do you prepare, reset, and clean up resources?
- Which failure paths can you exercise?
- What runtime, licensing, and access requirements apply?
For IaC workflows, also distinguish between accepting a resource definition and running the resulting workload. An API simulation may accept a request to create infrastructure without providing a working VM, database, or network behind it.
Keep real-cloud validation in the workflow
Emulation has limits. Passing locally does not establish full service parity or prove production behavior.
Identity and authorization, networking, quotas, consistency, and managed-service behavior can differ. Keep targeted tests in a controlled cloud environment for the guarantees your application depends on.
The value of local testing is a faster feedback loop, paired with a clear understanding of what still needs cloud validation.
Open source first, with transparent licensing
The repository prioritizes open-source tools. Within each section, they appear before other distributions and paid or commercial products.
Commercial tools are included where relevant to help readers compare options. Inclusion does not imply endorsement or a recommendation to purchase.
The list also distinguishes 💰 paid commercial conditions from 📜 vendor-specific terms, because software terms do not necessarily mean a fee is required. Unmarked tools still have licenses, and upstream terms should always be checked.
Help improve the list
I would like this to become a useful community reference for developers, testers, and cloud engineers.
If you use an emulator that is missing, spot an inaccurate description, or know an important limitation, please open an issue or contribute a pull request. The contribution guide explains what to include, such as upstream evidence, limitations, and any affiliation.
Explore Awesome Cloud Emulators on GitHub.
Which cloud dependency causes the most friction in your local development or testing workflow—and what have you found that helps?
If you find this useful, give the repo a ⭐ and share it with your colleagues and network to help more teams discover it.
Top comments (2)
The distinction between API acceptance and a running workload is useful. One addition to the comparison matrix could be "same contract fixture last run against emulator and real service", with versions and known differences recorded. For the object -> queue -> worker example, I'd include a lost acknowledgement after processing and a redelivered message, not only a successful round trip. That would help readers separate fast local confidence from the specific delivery semantics they still need to validate in the cloud.
Hi @launchgatecheck, this is great feedback. The guidance is now updated.