Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article summarizes the steps to develop and test locally by using the Azure Service Bus emulator.
The emulator runs as a Docker container on your local machine, providing a local Service Bus environment for development and testing. You can set up the emulator by using either an automated script (for quick setup) or by manually configuring Docker containers (for more control).
Azure Service Bus emulator is available via the Microsoft Container Registry (MCR).
Note
The Service bus emulator is available under the Microsoft Software License Terms.
Service Bus emulator isn't compatible with the community owned open source Service Bus Explorer
Prerequisites
- Minimum hardware requirements:
- 2 GB of RAM
- 5 GB of disk space
- Docker Desktop needs to be installed and running in the background.
Note
Even the automated script approach uses Docker containers behind the scenes to run the Service Bus emulator.
- Windows Subsystem for Linux (WSL) configuration (only for Windows):
Run the emulator
To run the Service Bus emulator, you can use an automated script or manually configure Docker containers. Both approaches result in the same containerized emulator running locally:
- Automated script: Uses prebuilt scripts to automatically set up and run the emulator containers with default configuration
- Docker container: Provides full control by letting you manually configure the emulator through Docker Compose files
Choose the approach that best fits your needs:
Before you run the automated script, you need to clone the Azure/azure-service-bus-emulator-installer repository locally.
Windows
Use the following steps to run the Service Bus emulator locally on Windows:
Open PowerShell and navigate to the directory where you cloned the common scripts folder by using
cd:cd <path to your common scripts folder> # Update this pathIssue wsl command to open WSL at this directory.
wslRun the setup script ./LaunchEmulator.sh.Running the script brings up two containers: the Service Bus emulator and SQL Server Linux (a dependency for the emulator).
./Launchemulator.sh
Linux and macOS
To run the Service Bus emulator locally on Linux or macOS:
- Run the setup script LaunchEmulator.sh. Running the script brings up two containers: the Service Bus emulator and SQL Server Linux (a dependency for the emulator).
Verify emulator is running
Regardless of which setup method you chose, the result is the same: the Service Bus emulator running in Docker containers on your local machine. The emulator consists of two containers:
- Service Bus emulator container: The main emulator service that provides Service Bus functionality
- SQL Server Linux container: A dependency that provides the backend storage for the emulator
You can verify the containers are running by checking Docker Desktop or using the command docker ps in a terminal.
Interact with the emulator
You can create and manage Service Bus entities—such as queues and topics—using the Service Bus Administration Client. By default, emulator uses config.json configuration file. You can also configure entities by making declarative changes to configuration file. To know more, visit create and manage entities within Service Bus emulator
Choosing the right connection string
The Service Bus emulator uses a static connection string, but the host value varies depending on how your application is deployed relative to the emulator. Use the appropriate connection string for your setup:
When the emulator container and interacting application are running natively on local machine, use following connection string:
"Endpoint=sb://localhost;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=SAS_KEY_VALUE;UseDevelopmentEmulator=true;"Applications (Containerized/Non-containerized) on the different machine and same local network can interact with Emulator using the IPv4 address of the machine. Use following connection string:
"Endpoint=sb://192.168.y.z;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=SAS_KEY_VALUE;UseDevelopmentEmulator=true;"Application containers on the same bridge network can interact with Emulator using its alias or IP. Following connection string assumes the name of Emulator container is "servicebus-emulator":
"Endpoint=sb://servicebus-emulator;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=SAS_KEY_VALUE;UseDevelopmentEmulator=true;"Application containers on the different bridge network can interact with Emulator using the "host.docker.internal" as host. Use following connection string:
"Endpoint=sb://host.docker.internal;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=SAS_KEY_VALUE;UseDevelopmentEmulator=true;"Important
By default, management operations using the Service Bus Administration Client require appending the port number to the emulator connection string. For example, when both the emulator and the application are running on the same machine, use the following connection string for administration operations:
"Endpoint=sb://localhost:5300;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=SAS_KEY_VALUE;UseDevelopmentEmulator=true;";For management operations, the emulator uses port 5300 by default. You can configure the emulator to use a different port if required. Refer to know more.
For the Service Bus Emulator, creating and managing entities via the Service Bus Administration client is natively supported only in .NET.
You can use the latest client SDKs to interact with the Service Bus emulator across various programming languages. To get started, refer to the Service Bus emulator samples on GitHub.