Queue Storage

Introduction

Azure Queue Storage is a messaging service for storing large numbers of messages that can be accessed from anywhere over HTTP or HTTPS. It is commonly used to decouple application components and build asynchronous processing workflows. Queue Storage is useful for buffering work items between producers and consumers. For more information, see What is Azure Queue Storage?

LocalStack for Azure provides a local environment for building and testing applications that make use of Azure Queue Storage. The supported APIs are available on our API Coverage section, which provides information on the extent of Queue Storage’s integration with LocalStack.

Getting started

This guide is designed for users new to Queue Storage and assumes basic knowledge of the Azure CLI and our lstk az proxy.

Launch LocalStack using your preferred method. For more information, see Introduction to LocalStack for Azure. Once the container is running, enable Azure CLI interception by running:

lstk az start-interception

Create a resource group

Create a resource group to contain your storage resources:

az group create \
  --name rg-queue-demo \
  --location westeurope

{
  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-queue-demo",
  "location": "westeurope",
  "managedBy": null,
  "name": "rg-queue-demo",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}

Create a storage account

Create a storage account in the resource group:

az storage account create \
  --name stqueuedemols \
  --resource-group rg-queue-demo \
  --location westeurope \
  --sku Standard_LRS

{
  ...
  "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-queue-demo/providers/Microsoft.Storage/storageAccounts/stqueuedemols",
  ...
  "name": "stqueuedemols",
  ...
  "placement": null,
  "primaryEndpoints": {
    "blob": "https://stqueuedemols.blob.core.azure.localhost.localstack.cloud:4566",
    ...
    "queue": "https://stqueuedemols.queue.core.azure.localhost.localstack.cloud:4566",
    ...
  },
  ....
}

Authentication

There are three ways to authenticate storage queue commands against the emulator:

Storage account key

Retrieve the account key and pass it with --account-name and --account-key:

ACCOUNT_KEY=$(az storage account keys list \
  --account-name stqueuedemols \
  --resource-group rg-queue-demo \
  --query "[0].value" \
  --output tsv)

az storage queue list \
  --account-name stqueuedemols \
  --account-key "$ACCOUNT_KEY"

Use --auth-mode login to authenticate with the current session credentials:

az storage queue list \
  --account-name stqueuedemols \
  --auth-mode login

Connection string

Bundle the account name and key into a single value:

CONNECTION_STRING=$(az storage account show-connection-string \
  --name stqueuedemols \
  --resource-group rg-queue-demo \
  --query connectionString -o tsv)

az storage queue list \
  --connection-string "$CONNECTION_STRING"

The remaining examples in this guide use connection strings for brevity.

Create and inspect a queue

Create a queue:

az storage queue create \
  --name app-queue \
  --connection-string "$CONNECTION_STRING"

{
  "created": true
}

Verify the queue exists:

az storage queue exists \
  --name app-queue \
  --connection-string "$CONNECTION_STRING"

{
  "exists": true
}

List queues in the storage account:

az storage queue list \
  --connection-string "$CONNECTION_STRING"

[
  {
    "approximateMessageCount": null,
    "metadata": null,
    "name": "app-queue"
  }
]

Put, peek, and get messages

Add a message to the queue:

az storage message put \
  --queue-name app-queue \
  --content "hello-from-localstack" \
  --connection-string "$CONNECTION_STRING"

{
  "content": "hello-from-localstack",
  ...
  "id": "a253ff4a-7b9c-434e-9c33-deae3070193c",
  ...
}

Peek at messages without consuming them:

az storage message peek \
  --queue-name app-queue \
  --connection-string "$CONNECTION_STRING"

[
  {
    "content": "hello-from-localstack",
    ...
    "id": "a253ff4a-7b9c-434e-9c33-deae3070193c",
    "insertionTime": "2026-02-27T07:45:14+00:00",
    ...
  }
]

Get (dequeue) a message from the queue, which makes it invisible to other consumers for the visibility timeout you set (when you omit --visibility-timeout, Azure Queue Storage uses a default of 30 seconds; see Get Messages):

az storage message get \
  --queue-name app-queue \
  --connection-string "$CONNECTION_STRING" \
  --output json

[
  {
    "content": "hello-from-localstack",
    ...
    "id": "a253ff4a-7b9c-434e-9c33-deae3070193c",
    "popReceipt": "...",
    ...
  }
]

Features

The Queue Storage emulator supports the following features:

Data plane REST API: Queue CRUD, message operations (put, peek, get, delete), queue metadata, stored access policies, and SAS token generation.
Control plane REST API: Create, get, and delete queues, and get and set queue service properties via Azure Resource Manager.
Queue service properties: Setting service properties stores what you send (such as CORS rules), validated as Azure does, and getting them returns the stored values. Setting an empty value echoes an empty resource.
Persistence: With persistence enabled, queue data survives a restart.
Multiple authentication modes: Storage account key, login credentials, and connection strings.
SAS and Shared Key validation: Shared Key, SharedKeyLite, and account, service, stored access policy, and user delegation SAS requests are validated. See Storage Account: Data plane authentication.

Limitations

Persistence must be enabled: Queue data survives a restart only when persistence is on. Without it, queue data is lost when the LocalStack emulator is stopped or restarted.
Service properties are stored, not applied: The emulator stores and returns the settings you set, such as CORS rules, but doesn’t act on them.
Unsupported control plane operations: Queue list, queue update, and queue service list are not yet supported.
Storage account keys: Keys are emulator-generated rather than managed by Azure.
Header validation: Unsupported request headers or parameters are silently accepted instead of being rejected.
API version enforcement: The emulator does not validate the x-ms-version header; all API versions are accepted.
RBAC enforcement is opt-in: By default, data-plane operations succeed regardless of role assignments. Set LS_AZURE_ENFORCE_RBAC to require the caller to hold a role such as Storage Queue Data Contributor; see Role Assignment: Enabling RBAC enforcement.

Samples

The following sample demonstrates how to use Queue Storage with LocalStack for Azure:

Azure Functions Sample with LocalStack for Azure

API Coverage

8 of 8 operations implemented

Operation ▲	Implemented ▼

Page 1 of 0

Was this page helpful?