For a while, local Azure development in my projects looked like this: Azurite for Blob and Queue Storage, the Microsoft Service Bus Emulator for messaging, the Cosmos DB Emulator for document storage, and nothing at all for Key Vault, Container Registry, or Entra. The last three were either skipped in local runs, mocked, or simply hit against a real Azure subscription when I needed them.
That worked, to a point. But the setup cost was real. Each emulator has its own Docker image, its own port range, its own quirks, and its own certificate story. Compose files grew. CI pipelines grew to match. And the services that had no emulator at all stayed untested locally, which is exactly the category where surprises tend to show up in production.
I wanted to see whether a single tool could cover the whole stack without making too many compromises.
What the old setup actually looked like
The previous CI compose file had three separate service containers. Azurite covered BlobServiceClient, QueueServiceClient, and TableServiceClient. The Service Bus Emulator added a second container with its own volume and a RabbitMQ dependency. The Cosmos DB Emulator added a third, and that one needed a minute and a half to initialise before tests could start on x64 machines. On Apple Silicon it did not start at all: the Linux container image is x64-only, and under Docker's Rosetta emulation layer the embedded database engine crashes during startup (GitHub issue #54, open since July 2022 with 149 comments). There is a separate vNext Linux emulator that does run on ARM, but it is a different codebase still in preview with its own coverage gaps. In practice, anyone on an M-series Mac either skipped Cosmos DB local testing entirely, ran a Windows VM, or hit real Azure. Key Vault calls were either mocked or skipped regardless of platform.
