Local Azure Development with Azurite and Emulators

Azurite is an open-source, cross-platform emulator for Azure Blob, Queue, and Table storage. It replaces the legacy Azure Storage Emulator (which only ran on Windows and had limited features). Azurite runs on Windows, macOS, and Linux, and supports all three storage services in a single process. The primary purpose is to allow developers to write and test code against a local endpoint that mimics the Azure Storage REST APIs, without needing an active Azure subscription or internet connectivity. This accelerates development, reduces costs, and enables offline testing.

Azurite implements the Azure Storage REST API protocol by listening on HTTP/HTTPS ports (default 10000 for blob, 10001 for queue, 10002 for table). When your application sends a request (e.g., PUT to create a blob), Azurite parses the request, validates authentication (shared key or SAS token), and performs the operation on the local file system. Data is stored in a configurable directory (default: %USERPROFILE%\.azurite on Windows, ~/.azurite on Linux/macOS). Azurite supports both in-memory and persistent storage modes. In persistent mode, data survives restarts; in-memory mode is for testing where state should not persist. Azurite also supports OAuth authentication via a local token endpoint, but for simplicity, most developers use the well-known connection string UseDevelopmentStorage=true which uses a fixed account name and key (Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==). This key is publicly known and must never be used in production.

To install Azurite globally via npm:

npm install -g azurite

To start Azurite with default settings:

azurite

To start with custom ports and location:

azurite --blobPort 10010 --queuePort 10011 --tablePort 10012 --location C:\MyStorage --debug

To verify Azurite is running, use a tool like curl or Azure Storage Explorer:

curl http://127.0.0.1:10000/devstoreaccount1?comp=list

This should return an XML listing of containers (empty initially).

Azurite works seamlessly with the Azure Storage SDKs (for .NET, Java, Python, Node.js, etc.). When you set the connection string to UseDevelopmentStorage=true in your app configuration, the SDK automatically resolves the endpoint to localhost. Azurite also integrates with Azure Functions local runtime, enabling local testing of blob/queue/table triggers. For Cosmos DB, a separate emulator exists (Cosmos DB Emulator) which runs on port 8081. Azurite does not emulate Cosmos DB. For Table storage, note that Azurite emulates the old Azure Table Storage API, not the newer Cosmos DB Table API. If your app targets Cosmos DB Table API, use the Cosmos DB Emulator instead.

Despite these limitations, Azurite is the recommended local development tool for Azure Storage.

A healthcare startup is building a patient records system using Azure Blob Storage for medical images. Developers work remotely, often with limited internet. They use Azurite to run the entire storage layer locally. Each developer has Azurite running on their machine with persistent storage in a project folder. They configure their ASP.NET Core app to use UseDevelopmentStorage=true in appsettings.Development.json. This allows them to write and test blob uploads, downloads, and metadata operations without any cloud connectivity. The team uses Azure Storage Explorer connected to the local endpoint to verify data. The main challenge is that Azurite does not enforce blob size limits, so a developer might upload a 5TB file locally that would fail in production. They mitigate this by adding a validation layer that checks blob size before upload. Also, since Azurite does not simulate network failures, they must manually test retry logic by stopping Azurite temporarily. Performance is not an issue because each developer works with small datasets.

A financial services company uses Azure DevOps for CI/CD. Their integration tests require Azure Storage. They run Azurite in a Docker container as part of the pipeline. The Docker image mcr.microsoft.com/azure-storage/azurite is used. The pipeline starts Azurite, runs tests, and then stops the container. The connection string is set to UseDevelopmentStorage=true but because the container runs on a different host, they use the full connection string with the container's IP address. They also use the --silent flag to reduce log noise. The tests cover blob, queue, and table operations. One issue they faced is that Azurite does not support shared access signatures (SAS) with stored access policies; they had to modify tests to use simple SAS tokens. Also, Azurite does not support blob lease duration beyond 60 seconds, so lease-related tests had to be adjusted. This approach saved costs by avoiding provisioning an actual storage account for every build.

A retail company uses Cosmos DB Table API for order processing. They need local development. They use the Cosmos DB Emulator (not Azurite) because Azurite only emulates the old Azure Table Storage API, which lacks features like global distribution and consistency levels. The Cosmos DB Emulator runs on port 8081 and provides a similar experience. They configure the connection string to point to localhost:8081 with the emulator's account key. The emulator supports most Cosmos DB features, including stored procedures, triggers, and UDFs. However, it has limitations: it runs on a single partition, so throughput is limited to 10,000 RU/s. They use it for unit tests and integration tests. The main pitfall is that the emulator does not enforce request unit (RU) consumption exactly like the cloud, so they must load test against the real service before production deployment.